Systems and methods for character development in online gaming

ABSTRACT

Certain embodiments provide a method for selecting an allocation of character attributes in a gaming system including selecting a set of characters, aggregating outcome data, aggregating allocation data, determining a correlation between outcome data and allocation data, and selecting an allocation based at least in part on the determined correlation. The set of characters includes at least one character and each character includes a set of attributes. Each attribute has an associated attribute value adapted to be adjusted. Each character is associated with an outcome record based at least in part on a competition. Outcome data is based at least in part on outcome records. Allocation data is based at least in part on each set of attributes and attribute values associated with each attribute in each set of attributes. The correlation is based at least in part on which attributes and attribute values correspond to which outcomes.

RELATED APPLICATIONS

The present application relates to and claims the benefit of U.S. Provisional App. No. 60/xxx,xxx, entitled “Systems and Methods for Online Gaming,” filed Aug. 3, 2006. The foregoing application is herein incorporated by reference in its entirety.

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

[Not Applicable]

MICROFICHE/COPYRIGHT REFERENCE

[Not Applicable]

BACKGROUND OF THE INVENTION

The presently described technology generally relates to computer gaming. More particularly, the presently described technology relates to systems and methods for character development in online gaming.

Role-playing games (RPGs), such as Dungeons and Dragons™, allow a player to develop a character through the course of game play. As a player uses a character during the course of an adventure or gaming session, the character gains experience points that may be used to increase characteristics or skills of the character. For example, a character may be built up from a lowly peasant to an overpowering hero by slaying numerous monsters encountered during an adventure.

Some RPGs may provide predetermined labels for a character. For example, a character's label might change each time the character increases in level. However, the labels are generally fixed or static for a given character class. For example, any character with the class of “fighter” might progress from “warrior” to “champion” when the character accumulates enough experience points to increase from a level 4 fighter to a level 5 fighter. Thus, once a player chooses a class for a character, the character's label is purely a function of a single aspect of the character: the character's level. The labels are not customized based on combinations of character features or attributes.

Typically, a player of an RPG controls a single character for a particular adventure. Sometimes a player may utilize the character across multiple adventures. However, typically once a character is “killed” in the course of an adventure, a player must start over by creating a new character.

In RPGs, it is unlikely a player would trade a character to another player. The player invests time and effort into building up and developing a character over a series of gaming sessions. This investment generally results in a personal attachment to the character, making a player reluctant to trade the character to someone else. Additionally, a major component of an RPG, as the name implies, is the role-playing of the character by the player. A character is more than just a collection of numbers representing characteristics and skills. Rather, characters have life breathed into them by their player. Thus, a player's attachment to a particular character, along with the role-playing elements of RPGs, results in a character rarely, if ever, being traded to another player.

Thus, RPGs allow a player to develop a single character. However, a player of an RPG typically does not play multiple characters at the same time. In addition, players do not typically trade characters. Moreover, while labels for characters in an RPG may change, available labels are predetermined and based on only a single aspect of the character.

Magic: The Gathering™ (“MTG”) combines elements of card games with RPGs. Typically, a card game includes a set number of cards, such as a deck, some or all of which are unique. For example, cards may have values, such as numbers from two to ten, jacks, kings, queens, aces, and jokers. As another example, cards may be distinguished by suits, such as hearts, clubs, spades, and diamonds. A card may be unique through a combination of value and suit, for example. Card games are limited in that the value of the cards and the rules of the game are generally fixed. In a game of MTG, two players compete against each other by taking turns playing cards, with the goal of inflicting a predetermined amount of damage on the opponent. For example, the first player to reduce their opponent's life value from 20 to 0 wins.

In MTG, there is a universe of hundreds of cards available, although during the course of any particular game, a player uses a deck of limited size, such as 60 cards. A card in MTG may represent creatures, artifacts, and spells, for example. In addition, MTG cards may have different colors, representing a specialization in certain kinds of abilities. MTG cards are fixed. That is, a particular card describes the abilities and/or effect of a particular creature or spell, for example. The MTG card does not change or evolve over the course of multiple games. During the course of game play, one card may modify the behavior of another card, but such a modification is specific to that particular game and does not persist across multiple games.

After playing a game of MTG, a player may use his cards in a subsequent game. That is, even if a creature card is defeated in the course of one game, that creature card may be used in subsequent games.

MTG also incorporates the concept of collectibility. That is, cards in MTG are collectables. Trading cards have long been collectables. Baseball cards are an example of a type of collectable trading card. In MTG, a particular card may be part of a set, for example. Players may then desire to collect all the cards in a set. Such a set may have greater value monetarily and/or within the game. In some instances, certain MTG cards may be scarce. As a result of scarcity, certain cards may have a higher perceived value due to the difficulty in obtaining such cards.

Another aspect of collectibility in MTG is that when a player purchases a pack of cards, the player does not know what cards are in the pack until the player opens the pack. Thus, players often end up with duplicates of cards which are more common. Players may then trade cards with each other to acquire cards they do not have.

Thus, a player of MTG typically has multiple cards of various types. In addition, players of MTG may trade cards. However, MTG cards have fixed values and/or characteristics.

Everquest™ (“EQ”) is an online RPG. A player creates an account with a login and password. The account is associated with a particular character. The player may then participate in quests in the online environment with his character. As the player is successful in attaining goals and defeating creatures in the game environment, experience points are awarded. The player may then increase the character's abilities by “spending” the experience points. Although a player may trade or sell access to his account, and thus his character, such actions are generally discouraged. In addition, a player may only control a single character through the player's account.

EQ does not support a mechanism to transfer a character as part of the gaming system. Players may auction a login and password to a character in an online forum such as eBay. The winning bidder then receives the login and password for the character and may take control of it. However, this transfer occurs outside the scope of the EQ system.

Characters in EQ are represented by certain features, such as a title and appearance, which are displayed to players while in the gaming environment. Games such as EQ may allow a player to pick a title or appearance for their character. However, these features cannot be changed by the gaming system based on one or more aspects of the character.

Thus, an EQ player controls a single character that may be developed. EQ characters are not traded as part of the game. In addition, an EQ player controls only a single character at a time. Furthermore, character features, such as appearance and title, are not altered based on the character's attributes or game experiences.

The automatic alteration of features of a character such as appearance and title would greatly enhance the game play environment for a player. Therefore, it is highly desirable to have a gaming system that provides customization of a character based at least in part on attributes of the character.

RPGs that allow character development, such as Dungeons and Dragons™ and EQ, often require a significant investment of time and effort by a player. In particular, some players choose to spend a large portion of their time deciding which characteristics or skills to improve and how to improve them.

These “micro-managing” players may discover certain advantageous allocation strategies that were not intended or anticipated by the game designers. For example, a micro-managing player may discover that certain skills are more advantageous in the game system than others. Typically, designers intend that no particular allocation of characteristics and skills will have an overwhelming effect on competitiveness.

In practice, the great complexity of many games makes determining a fair rule set an exceedingly difficult task. Characters with certain allocations of attributes are likely to vastly outperform other characters with different allocations. Moreover, the more advantageous allocations typically become known only after lengthy trial-and-error. Thus, players who invest large amounts of time playing the game are more likely to discover allocation strategies corresponding to more successful game performance.

Conversely, casual gamers want to enjoy game play, but are unable and/or unwilling to invest the time and effort of a micro-managing player. In current systems, casual gamers may be unable to enjoy competitive play because they are often unaware of the advantageous allocations described above. Moreover, automatic or default options provided by the game designers typically cannot level the playing field, as the game designers themselves are unaware of the imbalance.

Therefore, it is highly desirable to have a gaming system that allows a casual gamer to be competitive with players who micro-manage their characters.

Thus, there is a need for systems and methods for character development in online gaming.

BRIEF SUMMARY OF THE INVENTION

Certain embodiments of the present invention provide a method for selecting an allocation of character attributes in a gaming system including selecting a set of characters, aggregating outcome data, aggregating allocation data, determining a correlation between the outcome data and the allocation data, and selecting an allocation based at least in part on the determined correlation. The set of characters includes at least one character. Each character in the set of characters includes a set of attributes. Each set of attributes includes at least one attribute. Each attribute has an associated attribute value adapted to be adjusted. Each character is associated with an outcome record. Each outcome record is based at least in part on a competition. The outcome data is based at least in part on the outcome records. The allocation data is based at least in part on each set of attributes and the attribute values associated with each attribute in each set of attributes. The correlation is based at least in part on which attributes and attribute values correspond to which outcomes.

Certain embodiments of the present invention provide a method for adjusting an ancillary characteristic of a character in a game including selecting a character, selecting an ancillary characteristic associated with the character, selecting an attribute associated with the character based at least in part on the selected ancillary characteristic, and adjusting an ancillary characteristic value associated with the selected ancillary characteristic based at least in part on an attribute value associated with the selected attribute. The character is associated with at least one ancillary characteristic. Each ancillary characteristic is associated with an ancillary characteristic value. The character is associated with at least one attribute. Each attribute is associated with an attribute value. Each attribute value is adapted to be adjusted by a player.

Certain embodiments of the present invention provide a computer-readable medium including a set of instructions for execution on a computer, the set of instructions including a character set routine and a character development routine. The character set routine is configured to support a character set. The character set is adapted to include at least one character. Each character in the character set includes at least one attribute. At least one attribute of each character in the character set is adjustable by a player. The character development routine is configured to allow the player to adjust the at least one attribute of each character in the character set.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates an online, multi-player gaming system according to an embodiment of the present invention.

FIG. 2 illustrates a server for a gaming system according to an embodiment of the present invention.

FIG. 3 illustrates a functional view of a gaming system according to an embodiment of the present invention.

FIG. 4 illustrates an exemplary screen configuration for managing the characters of a player according to an embodiment of the present invention.

FIG. 5 illustrates a gaming system according to an embodiment of the present invention.

FIG. 6 illustrates an exemplary screen configuration for a development user interface that allows a player to develop a character according to an embodiment of the present invention.

FIG. 7 illustrates a flow diagram for a method for selecting an allocation of character attributes in a gaming system in accordance with an embodiment of the present invention.

FIG. 8 illustrates a flow diagram for a method for adjusting an ancillary characteristic of a character in a gaming system according to an embodiment of the present invention.

FIG. 9 illustrates a flow diagram for an example according to the method for adjusting an ancillary characteristic of a character in a gaming system.

The foregoing summary, as well as the following detailed description of certain embodiments of the present invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, certain embodiments are shown in the drawings. It should be understood, however, that the present invention is not limited to the arrangements and instrumentality shown in the attached drawings.

DETAILED DESCRIPTION OF THE INVENTION

Certain embodiments of the presently described technology include systems and methods for multi-character online gaming. Certain embodiments combine gaming system elements including collectibility, character development, and trading. In addition, certain embodiments further combine gaming system elements including war gaming, customization, online distribution, and/or online game play.

For example, in one embodiment, a gaming system called The Continuum™, collectibility, character development, trading, war gaming, customization, online distribution, and online game play are combined to create a gaming experience. The Continuum™ is an online, collectible, war game where the characters in the game develop like in a role-playing game, are customized to a player's tastes, and are traded like cards.

In The Continuum™, a player has a collection. The collection includes the characters associated with the player. Each character has one or more attributes. The attributes may include characteristics, statistics, and/or abilities, for example. For example, a character may have ratings for intelligence, strength, speed, and/or dexterity. As another example, a character may have attributes indicating offensive and/or defensive capabilities, skills, and strengths. These attributes may affect the character's performance in a competition such as a battle, for example. The characters in a player's collection may be grouped into one or more armies. A character may be in multiple armies. The armies may be configured for different types of competitions, for example.

A character in The Continuum™ has a point value. The point value may initially be fixed or predetermined when the character is purchased. The point value may reflect, in part, the rarity or scarcity of the character. For example, the more rare and/or powerful the character, the more points the character may be worth. In addition, the point value may reflect and/or be based at least in part on one or more attributes of the character, such as type, level, characteristics, abilities, ability levels, and/or equipment. As a character develops and its attribute values change, the point value of the character may change as well. Thus, the point value of a character in The Continuum™ may represent the effective strength of the character. The point values associated with characters may be used to level the playing field for battles. For example, each player may agree to play a certain point value game (e.g., a 100, 500, or 1000 point game). The gaming system then allows a player to field an army from the player's collection of any size up to the point value of the game.

After a battle, each player may be awarded a certain amount of experience points. The experience points may be used to increase the value of the character's attributes. That is, experience points may be “spent” to increase one or more attributes of a character at the player's discretion. Alternatively, the player may choose to have the experience points spent automatically, letting the gaming system determine how the points should be allocated. As a player is developed, the point value of the character may change.

Players of The Continuum™ may buy, sell, trade, and auction characters. For example, a player may purchase one or more new characters from the gaming system. The purchased characters may be determined randomly. Players may also swap characters with each other. Characters may be wagered as stakes and the winner of a battle may acquire the wagered character from the loser.

FIG. 1 illustrates an online, multi-player gaming system 100 according to an embodiment of the present invention. The gaming system 100 includes one or more players 1 10, one or more clients 120, a network 130, and a server 140. In certain embodiments, the server 140 includes a game engine 150 and a database 160.

A player 110 communicates with a client 120. In certain embodiments, a particular player 110 in a plurality of players communicates with a particular client 120 in a plurality of clients. In certain embodiments, more than one player 110 is in communication with a particular client 120. In certain embodiments, the player(s) 110 communicate with the client(s) 120 over a network. For example, a player 110 may communicate using a Web browser over the Internet with a client 120.

The client(s) 120 are in communication with the server 140. A client 120 may communicate with the server 140 over a network, such as network 130. The game engine 150 is in communication with the database 160.

In operation, a player 110 communicates with a particular client 120 to participate in the gaming system 100. As mentioned above, one or more players 110 may use one or more clients 120 to participate in the gaming system 100. The one or more players 110 may participate simultaneously, for example. The client 120 is adapted to provide the player 110 with an interface to the gaming system 100. That is, the player 110 may use the client 120 to interact with the gaming system 100. The player 110 may communicate commands and/or actions to be performed in the gaming system 100 using the client 120, for example. The client 120 may include a graphical user interface, for example.

In certain embodiments, the client 120 may be an application running on the computing system of the player 110. For example, the client 120 may include an executable program downloaded by the player 110. In certain embodiments, the client 120 may include a Web browser. The Web browser may run an Adobe/Macromedia Flash™ program to provide, at least in part, an interface for the player 120. In certain embodiments, at least a portion of the client 120 is downloaded. For example, the client 120 may be an application program downloaded from the server 140 across the network 130. As another example, a player 110 may download the client 120 from a distribution Web site.

The client 120 is adapted to communicate with the server 140. The client 120 may communicate with the server 140 over network 130. That is, the network 130 is adapted to facilitate communication between the client 120 and the server 140. The network 130 may be and/or include a local area network (LAN), for example. As another example, the network 130 may be and/or include the Internet.

The client 120 may communicate information, such as commands, data, and/or requests, to the server 140. The information to be communicated may be based at least in part on input from the player 110, for example. For example, the player 110 may use an interface of the client 120 to indicate that the player 110 wishes to purchase a new character. As another example, the player 110 may indicate with the client 120 to the server 140 to enter into a competition with another player.

In addition, the client 120 may receive data, such as commands, responses, and/or notifications, from the server 140. For example, the client 120 may receive account information from the server 140 to display to the user 110. As another example, the client 120 may receive updates regarding the position of characters belonging to the player 110 when the player 110 is involved in a competition with another player.

The server 140 is adapted to communicate with the client 120. As mentioned above, the server 140 may communicate with the client 120 over network 130. The server 140 receives information, such as commands, data, and/or requests, from the client 120. The server 140 transmits information, such as commands, responses, and/or notifications, to the client 120.

The server 140 is adapted to process the information communicated with the client 120. Processing the information may include allowing a player 110 to manage characters, exchange characters, initiate a competition, participate in a competition, and update account information, for example. Processing may include updating the state of a competition, acknowledging a request from the client 120, and delivering messages from other players 110, for example.

The server 140 is adapted to manage characters. A collection may be associated with a player 110. The collection may include one or more characters. A character may be in only one collection. That is, a given character may only be associated with a particular player 110 at any given time. Thus, the collections of players are disjoint. Characters may be exchanged from one collection to another, as discussed below. In addition, some characters may not be associated with a collection. For example, computer controlled characters may not be part of the collection of any player 110. As another example, characters for sale from the gaming system 100 may not be associated with a collection.

The characters in the collection of a player 110 may be grouped into one or more subsets. That is, the player 110 may be associated with one or more sets of characters. Each set of characters may contain one or more characters from the player's 110 collection. A character from the collection of the player 110 may be in more than one set of characters. For example, a player 110 may create multiple sets of characters, such as armies, for use in different situations while playing the game.

Each character has and/or is associated with one or more attributes. The attributes may include characteristics, statistics, and/or abilities, for example. For example, a character may have ratings for intelligence, strength, speed, and/or dexterity. As another example, a character may have attributes indicating offensive and/or defensive capabilities and strengths. As another example, a character may have attributes indicating a particular skill, such as lock-picking. These attributes may affect the character's performance in a competition such as a battle, for example. In certain embodiments, one or more of the attributes are adapted to be adjustable. That is, the attribute value associated with the attribute may be adjusted. The attribute value may be adjusted by a player 110, for example. As another example, the attribute value may be adjusted by the gaming system 100.

Similarly, a character has and/or is associated with one or more ancillary characteristics. The ancillary characteristics may include a title and/or appearance, for example. For example, a character may have a title ancillary characteristic that reflects weapon specialization and/or class, such as “swordsman” or “archer.” As another example, a character may have an appearance ancillary characteristic including an image or three-dimensional model of the character. The appearance ancillary characteristic may be visible to one or more of the players 110 during game play, for example. An ancillary characteristic is ornamental and serves to enhance the gaming environment for the player. However, an ancillary characteristic does not affect the character's performance in the gaming system 100. In certain embodiments, one or more of the ancillary characteristics are adapted to be adjustable. That is, the ancillary characteristic value associated with the ancillary characteristic may be adjusted. The ancillary characteristic may be adjusted by a player 110, for example. As another example, the ancillary characteristic value may be adjusted by the gaming system 100.

In certain embodiments, a character may be associated with a point value. The point value may reflect, in part, the rarity or scarcity of the character. For example, the more rare and/or powerful the character, the more points the character may be worth. In addition, the point value may reflect and/or be based at least in part on one or more attributes of the character, such as type, level, characteristics, abilities, ability levels, and/or equipment. Thus, the point value of a character may represent the effective strength of the character.

The server 140 is adapted to allow character exchange. For example, the server 140 may allow a player 110 to purchase, acquire, bid, request, and/or trade for one or more characters. As another example, the server 140 may allow a player 110 to sell, relinquish, auction, offer, and/or exchange one or more characters.

In certain embodiments, the character(s) involved in the exchange are, at least in part, randomly determined. That is, the server 140 may determine and/or select a character involved in an exchange at least in part out of the control of a player 110. For example, a player 110 may request that the server 140 provide a random character to be purchased by the player 110. As another example, a player 110 may purchase a set of five characters without knowing which five characters the player 110 will receive. As another example, two players may agree to exchange random characters of equal point value. As another example, the server 140 may randomly award one or more characters with a particular attribute, such as belong to a specific class or having a given ability, to a player 110.

In certain embodiments, the exchange is based at least in part on an auction. For example, a player 110 may acquire a character by providing the winning bid for the character. As another example, a character may be offered to a bidder in an auction.

In certain embodiments, one or more characters may be exchanged by transfer and/or trade. For example, one player 110 may agree to trade an associated character for a character associated with another player 110. As another example, a player 110 may direct the server 140 to transfer a character to another player 110.

In certain embodiments, a character is exchanged for money. Money may include, for example, in-game currency and/or real-world cash. For example, a player 110 may purchase a character from another player 110 by paying real-world cash using a credit card. As another example, a player 110 may acquire a character from the server 140 using an in-game currency such as gold pieces.

In certain embodiments, a fee is assessed on the exchange of a character. For example, a fee may be assessed to the player 110 acquiring a character. As another example, a fee may be assessed to the player 110 relinquishing a character. The fee may be money, as described above. For example, a player 110 may purchase a character from another player using cash and may be assessed a transaction fee. As another example, a player 110 may transfer a character to the winner of an auction for the character and be assessed a fixed-price fee of in-game currency. The fee may be assessed in a different form of money from the money used in an exchange. For example, two players may trade characters along with other items and/or in-game currency. A fee may be assessed to one or both players in the form of real-world cash, even though no real-world cash was involved in the exchange.

In certain embodiments, a player 110 acquires one or more characters based at least in part on a subscription. That is, a player 110 may indicate to the server 140 that the player 110 desires to acquire one or more characters based on a subscription. The player 110 may indicate the subscription by registering, for example. The subscription provides one or more characters to the player 110 at some time interval. For example, a player 110 may sign up for a monthly subscription where the player 110 acquires a pack of 5 characters every month. As another example, a player 110 may sign up for a subscription where the player 110 acquires a character every time a predetermined surplus of in-game currency is achieved.

The account of the player 110 may be automatically debited and/or charged based on the subscription, for example. Alternatively, a player 110 may be prompted whether an acquisition based on the subscription should be performed. The prompt may indicate default behavior. For example, the acquisition may occur within five days of a notification unless the player 110 indicates to the contrary to the server 140.

As is discussed in more detail below, in certain embodiments, an exchange can occur based at least in part on competition. For example, an exchange may occur based at least in part on the result of a competition. As another example, an exchange may occur based at least in part on an occurrence during a competition, such as the capture of an item, geographic location, or character.

The server 140 is adapted to allow a competition. That is, the server 140 supports at least one competition involving at least one player 110. For example, a first player 110 may compete with a second player 110. The players compete using one or more characters associated with each player. The players may compete with each other and/or against other players, for example. That is, one or more players 110 may compete using their associated characters against characters associated with one or more other players 110. For example, three players 110 may be involved in a three-way, every-player-for-themselves battle. As another example, two players 110 may compete co-operatively against two other players 110.

In certain embodiments, a player 110 may manually select other participants in a competition. For example, a player 110 may select a buddy to compete with. In certain embodiments, a player 110 may request a competition where the other participants are similarly matched. That is, a player 110 may request to be matched with one or more other players 110 who are also looked to be matched for a competition. The matching of players for a competition may be based on one or more competition parameters specified by the player 110 requesting the match. For example, the player may request a competition with a particular minimum, maximum, or range of point values. That is, as discussed above, characters may have associated point values and the match may limit the sum of the point values of the characters participating in the competition. For example, a player 110 may request to be matched for a competition with another player, where each player is allowed to participate with characters having point values up to 1000. The player 110 may use a set of characters, such as an army, that the player 110 has previously constructed for use in a 1000 point maximum value competition. Other parameters may be specified for the match, such as types of stakes to be wagered (discussed below), length of game, and/or map size.

The competition may include a battle between the characters, for example. As another example, the competition may include a game. The game may be similar to capture-the-flag, king-of-the-hill, annihilation, or an objective-based assault, for example.

In certain embodiments, the competition includes one or more characters controlled by a computer, such as an artificial intelligence. The computer may be the server 140, for example. For example, a player 110 may battle against characters controlled by the server 140. As another example, one or more players 110 may compete in cooperation with and/or against characters controlled by the server 140.

In certain embodiments, the competition is turn-based. For example, three players 110 competing against each other may take turns issuing commands to their respective characters involved in the competition. In certain embodiments, the competition is substantially real-time. For example, two players 110 competing against each other may issue orders to their associated characters simultaneously.

In certain embodiments, one or more players 110 may wager stakes on the outcome of a competition. For example, two players 110 competing in a battle against each other may wager an agreed-upon amount of money on the outcome of the battle. The money may be in-game currency and/or real-world cash, for example. The amount wagered may be a fixed amount or a computed amount. For example, a player 110 may wager 10% of the player's in-game currency at the end of the competition. As another example, a player 110 may wager money based on the number of characters left standing at the end of the competition. Thus, if a player 110 wins by a larger margin, more money is won, for example.

In certain embodiments, the stakes include one or more characters in the collection of the player 110. For example, two players 110 may each select one of their opponent's characters to be awarded upon winning the contest. As another example, each player 110 participating in a competition may designate one or more characters to wager on the outcome of the competition. As another example, the characters wagered may be specified by a percentage of the total point value of the collection of the player 110.

When stakes include one or more characters, the exchange capabilities of the server 140 described above may be invoked. For example, the winner of a battle may acquire a character that has been wagered as stakes in the battle by another player. In certain embodiments, the exchange capabilities of the server 140 are at least partially integrated with the competition capabilities of the server 140.

Based on the outcome of a competition, experience points may be awarded. Alternatively, in certain embodiments, experience points may be purchased with money. In certain embodiments, experience points may be acquired from another player 110. As mentioned above, a character may be developed over the course of game play. The experience points may be used to adjust the attributes of one or more characters. For example, a player 110 may use experience points to improve the characteristics and/or abilities of one or more characters in the collection of the player 110. In certain embodiments, the player 110 may manually allocate the experience points to adjust a character's attributes. In certain embodiments, the player 110 may have the experience points automatically allocated by the gaming system 100.

In certain embodiments, before a competition, a player 110 may receive a scouting report on the characters of another player 110 participating in the competition. The scouting report may include details of the number of the characters in the other player's collection, the attributes of those characters, the types of those characters, the point values of those characters, the levels of those characters, and/or outcomes of prior competitions the other player has been involved in, for example.

In certain embodiments, the server 140 is adapted to support merchandising. That is, the gaming system 100 may provide merchandise using, at least in part, the server 140. The merchandise may be based at least in part on a character. For example, the gaming system 100 may allow a player 110 to purchase merchandise, such as a toy, action figure, poster, trading card, comic book, clothing, animation, and/or apparel, based on one or more of the player's characters. For example, the gaming system 100 may allow a player 110 to purchase an action figure similar in appearance to a character in the collection of the player 110. As another example, the gaming system 100 may allow a player 110 to purchase a comic book illustrating a competition the player 110, or a particular character of the player 110, was involved in.

In certain embodiments, the processing by the server 140 described above is performed at least in part by the game engine 150 and/or the database 160. For example, the game engine 150 may be adapted to provide character exchange, competition, and/or character development capabilities. As another example, character data and/or account information for a player 110 may be stored in the database 160.

The game engine 150 may include one or more components for tasks such as communicating with the client 120, exchanging one or more characters, and handling competitions between one or more players 110. The game engine 150 may be implemented on a single computing system or across multiple computing systems. The game engine 150 may include fault tolerant features to allow continued operation in the event that one or more components fail.

The database 160 may be utilized by the game engine 150. The database 160 may store information regarding the state of the gaming system 100, for example. For example, account information for the players 10 may be stored in the database 160 and referenced by the game engine 150 for authorization and billing purposes. As another example, the database 160 may store information relating to the characters and collection of a player 110.

As discussed above, the components, elements, and/or functionality of the gaming system 100 may be implemented alone or in combination in various forms in hardware, firmware, and/or as a set of instructions in software, for example. Certain embodiments may be provided as a set of instructions residing on a computer-readable medium, such as a memory, hard disk, DVD, or CD, for execution on a general purpose computer or other processing device.

FIG. 2 illustrates a server 200 for a gaming system according to an embodiment of the present invention. The server 200 may be similar to the server 140, discussed above, for example. The server 200 includes a gaming engine 250 and a database 260. The gaming engine 250 may be similar to the gaming engine 150, discussed above, for example. The database 260 may be similar to the database 160, discussed above, for example.

The gaming engine 250 includes a communication component 252, an exchange component 254, a competition component 256, and a character development component 258. The database 260 includes one or more character sets 265.

The gaming engine 250 is in communication with the database 260. The communication component 252 is in communication with the exchange component 254, the competition component 256, and the character development component 258.

In operation, a player communicates with the server 200 using a client. The player may be similar to the player 110, described above, for example. The client may be similar to the client 120, described above, for example. For example, the player may communicate with the server 200 to sign on to the gaming system. As another example, the player may communicate with the gaming engine 250 as part of playing the game, including activities such as trading characters, developing characters, and engaging in competitions with other players.

The gaming engine 250 is adapted to allow one or more players, such as players 110, to participate in the game. The gaming engine 250 is adapted to communicate with the players. The communication may be handled at least in part by communication component 252, for example. The communication may be between the server 200 and one or more clients. The clients may be similar to the clients 120, described above, for example. Information such as commands, data, requests, responses, acknowledgements, and notifications may be communicated between the gaming engine 250 and the players.

The gaming engine 250 is adapted to process information communicated with the players. The processing may be performed at least in part by the exchange component 254, the competition component 256, and/or the character development component 258, for example. For example, a player 110 may request a character be exchanged for in-game currency associated with the player's account. The request may be processed by the exchange component 254. As another example, the competition component 256 may send an update to the player indicating the current state of a battle between the player and another player. As another example, a player 110 may request that accumulated experience points be spent to adjust the attributes of a character in the collection of the player 110. The request may be processed by the character development component 258.

The communications with the player and/or the client may be handled by the communication component 252. The communication component 252 is adapted to communicate with one or more clients, such as clients 120. The communications component 252 may communicate with the player 110 through the client 120, for example. The communication with the player may be over a network such as the Internet or a LAN, for example. Information, such as commands, data, and/or requests, may be received from the player 110 and/or the client 120, for example. Information, such as commands, responses, and/or notifications, may be communicated to the player 110 and/or the client 120, for example.

The exchange component 254 is adapted to allow a character to be exchanged. For example, the exchange component 254 may allow a player 110 to purchase, acquire, bid, request, and/or trade for one or more characters. As another example, the exchange component 254 may allow a player 110 to sell, relinquish, auction, offer, and/or exchange one or more characters. The character may be a new character for the player 110, for example. The character may be exchanged for money, such as in-game currency and/or real-world cash, for example.

In certain embodiments, the character(s) involved in the exchange are, at least in part, randomly determined. That is, the exchange component 254 may determine and/or select a character involved in an exchange at least in part randomly. For example, a player 110 may request that the server 200 provide a random character to be purchased by the player 110. The server 200, in turn, utilizes the exchange component 254 to determine the random character and initiate the exchange to the player 110. As another example, two players may agree to exchange random characters of equal point value. After each player's assent is signaled to the server 200, the exchange component 254 may perform the exchange.

In certain embodiments, the exchange component 254 is adapted to allow an exchange based at least in part on an auction. For example, a player 110 may acquire a character by providing the winning bid for the character. The exchange component 254 may then exchange the character from the offering player's collection to the winning player's collection.

In certain embodiments, the exchange component 254 is adapted to allow a character to be exchanged for money. As discussed above, money may include, for example, in-game currency and/or real-world cash. For example, a player 110 may purchase a character from another player 110 by paying real-world cash using a credit card. As another example, a player 110 may acquire a character from the server 200 using an in-game currency such as gold pieces. The exchange component 254 is adapted to perform the exchange and assign the character to the proper player's character set and debit the money from the appropriate account.

In certain embodiments, the exchange component 254 assesses a fee on the exchange of a character. For example, a fee may be assessed to the player 110 acquiring a character. As another example, a fee may be assessed to the player 110 relinquishing a character. The fee may be money, as described above. For example, a player 110 may purchase a character from another player using cash and may be assessed a transaction fee. As another example, a player 110 may transfer a character to the winner of an auction for the character and be assessed a fixed-price fee of in-game currency. The fee may be assessed in a different form of money from the money used in an exchange. For example, two players may trade characters along with other items and/or in-game currency. A fee may be assessed to one or both players in the form of real-world cash, even though no real-world cash was involved in the exchange.

The competition component 256 is adapted to allow one or more players to compete in a competition. That is, the competition component 256 supports at least one competition involving at least one player 110. For example, a first player 110 may compete with a second player 110. The players compete using one or more characters associated with each player. The players may compete with each other and/or against other players, for example. That is, one or more players 110 may compete using their associated characters against characters associated with one or more other players 110. For example, three players 110 may be involved in a three-way, every-player-for-themselves battle. As another example, two players 110 may compete co-operatively against two other players 110.

In certain embodiments, a player 110 may manually select other participants in a competition. For example, a player 110 may select a buddy to compete with. In certain embodiments, a player 110 may request a competition where the other participants are similarly matched. That is, a player 110 may request to be matched with one or more other players 110 who are also looked to be matched for a competition. The matching of players for a competition may be based on one or more competition parameters specified to the competition component 256 by the player 110 requesting the match. For example, the player may request a competition with a particular minimum, maximum, or range of point values. That is, as discussed above, characters may have associated point values and the match may limit the sum of the point values of the characters participating in the competition. For example, a player 110 may request to be matched for a competition with another player, where each player is allowed to participate with characters having point values up to 1000. The player 110 may use a set of characters, such as an army, that the player 110 has previously constructed for use in a 1000 point maximum value competition. Other parameters may be specified for the match, such as types of stakes to be wagered, length of game, and/or map size.

The competition may include a battle between the characters, for example. As another example, the competition may include a game. The game may be similar to capture-the-flag, king-of-the-hill, annihilation, or an objective-based assault, for example.

In certain embodiments, the competition includes one or more characters controlled by the competition component 256. For example, a player 110 may battle against characters controlled by the competition component 256. As another example, one or more players 110 may compete in cooperation with and/or against characters controlled by the competition component 256.

In certain embodiments, the competition is turn-based. For example, three players 110 competing against each other may take turns issuing commands to their respective characters involved in the competition. In certain embodiments, the competition is substantially real-time. For example, two players 110 competing against each other may issue orders to their associated characters simultaneously.

In certain embodiments, the competition component 256 supports wagering stakes on the competition. For example, two players 110 competing in a battle against each other may wager an agreed-upon amount of money on the outcome of the battle. The money may be in-game currency and/or real-world cash, for example. The amount wagered may be a fixed amount or a computed amount. For example, a player 110 may wager 10% of the player's in-game currency at the end of the competition. As another example, a player 110 may wager money based on the number of characters left standing at the end of the competition. Thus, if a player 110 wins by a larger margin, more money is won, for example.

In certain embodiments, the stakes include one or more characters in the character set of the player 110. For example, two players 110 may each select one of their opponent's characters to be awarded upon winning the contest. As another example, each player 110 participating in a competition may designate one or more characters to wager on the outcome of the competition.

When stakes include one or more characters, the exchange capabilities of the exchange component 254, described above, may be utilized. For example, the winner of a battle may acquire a character that has been wagered as stakes in the battle by another player. In certain embodiments, the exchange component 254 is at least partially integrated with the competition component 256.

In certain embodiments, when a character is defeated in a competition, the character is still available for use in subsequent competitions. That is, the character persists across competitions. In certain embodiments, when a character is defeated in a competition, the character is “dead” and may not be subsequently utilized. In certain embodiments, when a character is defeated in a competition, the character is captured by the victorious player and is placed into the character set of the victorious player and removed from the collection of the losing player. The result of a defeat of a character during a competition may be determined based on the stakes wagered for the competition. The transfer of a character may be facilitated by the exchange component 254, for example.

The character development component 258 is adapted to allow a player 110 to adjust one or more attributes of a character associated with the player 110. As discussed earlier, a character is associated with attributes and ancillary characteristics that may be adjusted. In certain embodiments, the character development component 258 allows a player 110 to spend experience points to adjust the value of one or more attributes of a character. For example, a player 110 may spend experience points to increase a character's dexterity. As another example, a player 110 may spend experience points to increase a character's proficiency with a sword.

In certain embodiments, the character development component 258 allows a player 110 to procure a new attribute for a character. The player 110 may spend experience points to acquire the new attribute, for example. For example, a player 110 may spend experience points to add a skill to the character. As another example, the player 110 may spend in-game currency to give a character the ability to use a crossbow. As another example, a player 110 may acquire a lock-picking ability for a character when the character successfully completes a competition.

In certain embodiments, the character development component 258 allows a player 110 to adjust one or more ancillary characteristics of a character. For example, a player 110 may select a new title for a character. As another example, a player 110 may select a new appearance for a character. In certain embodiments, a player 110 may spend accumulated experience points to adjust an ancillary characteristic. In certain embodiments, a player 110 may spend money such as in-game currency to adjust an ancillary characteristic. In certain embodiments, a player 110 may adjust an ancillary characteristic based on the outcome of a competition. For example, a player may win a particular battle and add the name of the battle to the list of the character's accomplishments ancillary characteristic.

In certain embodiments, the character development component 258 allows a player 110 to procure new ancillary characteristics for a character. For example, a player 110 may spend experience points to assign a new icon to a character during battles. As another example, a player 110 may assign an audio “signature” to a character, which plays when the player is actively managing the character and/or when the character performs an action.

In certain embodiments, the character development component 258 is adapted to automatically adjust a character's attributes and/or ancillary characteristics based on game situations. For example, the character development component 258 may automatically adjust a character's attributes, attribute values, ancillary characteristics, and/or ancillary characteristic values based on the amount of experience points accumulated. As another example, the character development component 258 may automatically adjust a character's title based on the character's skill or experience with a particular weapon or weapons. As another example, the character development component 258 may automatically modify a character's appearance based on the attribute value of a particular attribute. For example, the appearance may be modified to depict larger muscles on a character as the character's strength attribute value increases.

The character development component 258 is adapted to adjust a character's attributes according to an allocation scheme. In certain embodiments, the allocation scheme is based at least in part on a correlation between attribute allocations and competition outcomes of other characters. For example, the allocation scheme may be based on the attributes and/or associated attribute values that tend to be associated with characters that win a certain percentage of battles. As another example, the allocation scheme may be based on the relative attribute values that tend to be associated with attributes of characters that win a certain percentage of battles. As another example, the allocation scheme may be based on the choices made to improve characters that win a certain percentage of battles, such as attribute value adjustments and acquisition of new attributes.

In certain embodiments, the character development component 258 supports a “hall of fame” entry ancillary characteristic for a character, viewable by other players 110. Entry may be based on the achievement of certain criteria. For example, the criteria for entry could be based on the achievement of a particular goal or goals. Goals could include winning a certain number of competitions, successfully completing a particular quest, reaching a particular attribute value, and/or accumulating a certain amount of experience points, for example.

In certain embodiments, the character development component 258 may assign a detailed storyline ancillary characteristic to a character based on the achievement of a particular goal or goals. For example, a character that participated in a battle may be assigned a storyline that corresponds to the character's actions during the battle while adding narrative detail for dramatic effect. As another example, a character that has developed an archery skill past a certain level may be assigned a storyline that includes narrative detail referring to the character's mastery of the bow and arrow.

The database 260 is adapted to manage characters. Each character may be associated with one or more character sets 265. Each character set 265 is associated with a player. More than one character set 265 may be associated with a particular player. A particular character may only be associated with one particular player 110 at any given time, although, as mentioned, the particular character may be included in more than one character set 265. Characters may be exchanged from one character set 265 to another character set 265, as discussed above. A character set 265 may be an army, for example.

The database 260 may manage attributes associated with each character. The attributes may include characteristics, statistics, and/or abilities, for example. For example, a character may have ratings for intelligence, strength, speed, and/or dexterity. As another example, a character may have attributes indicating offensive and/or defensive capabilities and strengths. These attributes may affect the character's performance in a competition such as a battle, for example.

The database 260 may manage ancillary characteristics associated with each character. The ancillary characteristics may include a title and/or appearance, for example. For example, a character may have a title ancillary characteristic that reflects weapon specialization and/or class, such as “swordsman” or “archer.” As another example, a character may have an appearance ancillary characteristic including an image or three-dimensional model of the character. The appearance ancillary characteristic may be visible to one or more of the players 110 during game play, for example. An ancillary characteristic is ornamental and serves to enhance the gaming environment for the player. However, an ancillary characteristic does not affect the character's performance in a gaming system.

The database 260 may be utilized by the game engine 250. The database 260 may store information regarding the state of the gaming system, for example. For example, account information for the players 110 may be stored in the database 260 and referenced by the game engine 250 for authorization and billing purposes. As another example, the database 260 may store information relating to the characters and collection of a player 110, such as the characters' attributes, attribute values, ancillary characteristics, and ancillary characteristic values.

The information stored and managed by the database 260 may be based on one or more schemas. For example, an account schema may be used to represent information pertaining to the account of the players 110. As another example, a schema may manage game play information for a player 110. Information such as characters in the character set 265 of the player 110 may be tracked with the schema, along with statistics and configuration options. As another example, data relating to competitions may be stored in the database 260 based on a schema.

As discussed above, the components, elements, and/or functionality of the server 200 may be implemented alone or in combination in various forms in hardware, firmware, and/or as a set of instructions in software, for example. Certain embodiments may be provided as a set of instructions residing on a computer-readable medium, such as a memory, hard disk, DVD, or CD, for execution on a general purpose computer or other processing device.

FIG. 3 illustrates a functional view of a gaming system 300 according to an embodiment of the present invention. The gaming system 300 may be similar to the gaming system 100, described above, for example. The gaming system 300 includes a communication processor 310, an account processor 320, a competition processor 330, an exchange processor 340, and a development processor 350. The communication processor 310 is in communication with the account processor 320, the competition processor 330, the exchange processor 340, and the development processor 350.

In operation, the communication processor 310 handles communication with a player. The communication processor 310 may communicate information to the player about events in the gaming system, for example. For example, the communication processor 310 may transmit messages from other components of the gaming system 300, such as the account processor 320, to the player.

The communication processor 310 may be implemented using a client and a communication component. The client may be similar to the client 120, described above, for example. The communication component may be similar to the communication component 252, described above, for example.

The communication processor 310 may present a graphical user interface to a player, such as player 110. Alternatively, the communication processor 310 may provide data to a separate processor that provides the interface directly to the player. For example, the communication processor 310 may provide data to a Adobe/Macromedia Flash™ application running in a Web browser on the player's computer.

The communication processor 310 may receive information from the player. For example, the player may request to be logged-on or authenticated to the gaming system 300. The player may communicate a username and password to the gaming system 300. The communication processor may receive the username and password from the player and pass the username and password to the account processor 320. The account processor 320 may determine the password is valid for the username to authenticate the user. The account processor 320 may register the player as being logged-in as a result of the successful authentication. The account processor 320 may then provide an indicator to the communication component 310 that the player has been properly authenticated. The communication component 310 may then send a message to the player indicating the successful authentication.

The account processor 320 handles processing related to the account of a player. For example, the account processor 320 maintains the collection of the player. The collection includes the characters associated with the player. The account processor 320 may store information such as the password, billing information, and account preferences, for example. As discussed above, the account processor 320 may authenticate a player, for example. As another example, the account processor 320 may allow a character to be added or removed from the collection and/or a character set associated with a player. The addition or removal of a character from a player's collection by the account processor 320 may occur in cooperation with the exchange processor 340, discussed below.

The competition processor 330 handles setting up, running, and completing a competition. The competition may involve one or more players. Setting up the competition may include, for example, matching two or more players to compete. Setting up the competition may include wagering stakes on the outcome of the competition. Setting up the competition may include selecting the characters to be included in the competition. For example, two players may agree to participate in a competition using a maximum point value of characters on each side. For example, a player may agree to field an army in the competition where the total point value of the characters in the army does not exceed 1000. The competition processor 330 may determine the point value of a character based on the attribute values of the character. For example, a character with higher attribute values may have a higher point value.

The competition processor 330 may also handle running the competition. Running the competition may include deploying the characters of the players on a map, for example. The characters may move around a landscape over the course of the competition. Characters from opposing players may engage in combat during the competition. In certain embodiments, when a character is defeated in a competition, the character is still available for use in subsequent competitions. In certain embodiments, when a character is defeated in a competition, the character is “dead” and may not be subsequently utilized. In certain embodiments, when a character is defeated in a competition, the character is captured by the victorious player and is placed into the collection of the victorious player and removed from the collection of the losing player. The result of a defeat of a character during a competition may be determined based on the stakes wagered for the competition. The transfer of a character may be facilitated by the exchange processor 340, for example.

The competition processor 330 may also handle the completion of a competition. When a competition has been won, the winning player receives the stakes wagered by opposing players. As discussed above, stakes may include characters and/or money, for example.

The competition processor 330 may be implemented at least in part with a competition component. The competition component may be similar to the competition component 256, discussed above, for example.

The exchange processor 340 handles exchanges involving a character. An exchange of a character may include the character being purchased, acquired, bid for, requested, traded, sold, relinquished, auctioned, and/or offered. A character may be exchanged for another character and/or money, for example. For example, a character may be purchased by a player from the exchange processor 340. Money is transferred from the account of the player and the purchased character is added to the collection of the player. As another example, a player may offer a character for sale at an auction. Other players may bid on the character, and the winning bidder may receive the character in exchange for whatever was bid. The exchange processor 340 may assess a transaction fee on an exchange. For example, a player 110 may purchase a character from another player and be assessed a transaction fee by the exchange processor 340. The exchange processor 340 may work in cooperation with the competition processor 330. For example, the exchange processor 340 may transfer a wagered character to the winner of a competition supported by the competition processor 330.

The exchange processor 340 may be implemented at least in part with an exchange component. The exchange component may be similar to the exchange component 254, discussed above, for example.

The development processor 350 handles the development of a character. For example, a player may receive development or experience points after winning a competition supported by the competition processor 330. The experience points may be used by the player to develop a character in the collection of the player. A player may spend experience points to add and/or adjust one or more attributes, for example. A player may spend experience points to add and/or adjust one or more ancillary characteristics, for example.

In certain embodiments, the development processor 350 is adapted to automatically adjust a character's attributes and/or ancillary characteristics based on game situations. For example, attributes, attribute values, ancillary characteristics, and/or ancillary characteristic values may be automatically adjusted based on the amount of experience points accumulated. As another example, a character's title may be automatically changed based on the character's skill or experience with a particular weapon or weapons. As another example, a character's appearance may be automatically changed based on the attribute value of a particular attribute.

In certain embodiments, the development processor 350 is implemented at least in part with a character development component. The character development component may be similar to the character development component 258, described above, for example.

As discussed above, the processors, components, elements, and/or functionality of the gaming system 300 may be implemented alone or in combination in various forms in hardware, firmware, and/or as a set of instructions in software, for example. Certain embodiments may be provided as a set of instructions residing on a computer-readable medium, such as a memory, hard disk, DVD, or CD, for execution on a general purpose computer or other processing device.

FIG. 4 illustrates an exemplary screen configuration for managing the characters of a player according to an embodiment of the present invention. The screen configuration may be provided by a client similar to the client 120, described above, for example. The management screen may allow a player to build armies or sets of characters, equip a character with an item, and/or develop a character in the collection of the player. For example, the management screen may allow a player to browse the characters in the collection associated with the player. As another example, a player may view and/or edit attributes and/or ancillary characteristics of a particular character. The particular character may be selected from the list of characters in the collection of the player. The view of the particular character may include a picture of the character and access to a detailed back-story for the character. As another example, the management screen may allow a user to adjust the attributes and/or ancillary characteristics of a character.

FIG. 5 illustrates a gaming system 500 according to an embodiment of the present invention. The gaming system 500 may be similar to the gaming system 100 or the gaming system 300, described above, for example. The gaming system includes a player 510, a client 520, a network 530, and a server 540. The player 510 may be similar to the player 110, described above, for example. The client 520 may be similar to the client 120, described above, for example. The network 530 may be similar to the network 130, described above, for example. The server 540 may be similar to the server 140 or the server 200, described above, for example.

The server 540 includes a character database 550, a correlation database 560, and a game engine 570. The game engine 570 is in communication with the character database 550 and the correlation database 560.

The character database 550 may be similar to the database 160 or the database 260, described above, for example. The character database 550 includes one or more character sets 552. The character sets 552 may be similar to the character sets 265, described above, for example. Each character set 552 includes one or more characters 554. Each character is associated with one or more attributes 556 and one or more ancillary characteristics 558.

The correlation database 560 may be part of a database similar to the database 160 or the database 260, described above, for example. The correlation database includes outcome data 564 and allocation data 568. In certain embodiments, the correlation database 560 is combined with the character database 550. In certain embodiments, the outcome data 564 and allocation data 568 exist in separate databases.

The outcome data 564 includes the results of one or more engagements and/or competitions. For example, the outcome data 564 may include results for one or more players 510, for example. As another example, the outcome data 564 may include results for one or more characters 554, for example. The outcome data 564 may include the results of battles, for example. As another example, the outcome data 564 may include indicators of the number or percentage of competitions won and/or lost.

In certain embodiments, the outcome data 564 includes an indicator of which competition results correspond to which characters 554. For example, the outcome data 564 may include an indicator that a particular “win” percentage corresponds to a particular character 554. In certain embodiments, the outcome data 564 includes an indicator of which competition results correspond to which players 510. For example, the outcome data 564 may include an indicator that a particular “win” percentage corresponds to a particular player 510.

The allocation data 568 includes information on the allocation or distribution of attributes 556 and/or attribute values for one or more characters 554. In certain embodiments, the allocation data 568 is based on one or more attributes 556 and associated attribute values for one or more characters 554. For example, the allocation data 568 may include information on the allocation of attributes 556 and associated attribute values for each character 554 in the gaming system 500. As another example, the allocation data 568 may include information on the allocation of the attributes 556 and associated attribute values for each character 554 in each character set 552 associated with a set of players. The set of players may include all players 510 using the gaming system 500 or a subset of players 510 using the gaming system 500.

In certain embodiments, the allocation data 568 includes a record of one or more choices made when improving a character 554. For example, the allocation data 568 may include “+20,” “+50,” and “+10” for the attribute values associated with the “strength,” “dexterity,” and “intelligence” attributes 556, respectively. The changes in attribute values may correspond to the adjustments chosen by a player 510 when the character 554 advanced to the character's current level, for example. As another example, the changes in attribute values may correspond to the adjustments chosen by a gaming engine 570 when the character 554 advanced to the character's current level.

The game engine 570 may be similar to the game engine 150 or the game engine 250, described above, for example. The game engine 570 includes a communication component 572, a character development component 574, and a correlation component 576.

The communication component 572 may be similar to the communication component 252, described above, for example. The character development component 574 may be similar to the character development component 258, described above, for example.

The character development component 574 is in communication with the communication component 572, the correlation component 576, and the character database 550. The correlation component 576 is in communication with the character development component 574 and the correlation database 560.

In operation, a player 510 communicates with a particular client 520 to participate in the gaming system 500. Similar to the discussion above, one or more players 510 may use one or more clients 520 to participate in the gaming system 500. The client 520 is adapted to provide the player 510 with an interface to the gaming system 500. That is, the player 510 may use the client 520 to interact with the gaming system 500. The player 510 may communicate commands and/or actions to be performed in the gaming system 500 using the client 520, for example.

The client 520 is adapted to communicate with the server 540. The client 520 may communicate with the server 540 over network 530. That is, the network 530 is adapted to facilitate communication between the client 520 and the server 540.

The server 540 is adapted to communicate with the client 520. As mentioned above, the server 540 may communicate with the client 520 over network 530. The server 540 receives information, such as commands, data, and/or requests, from the client 520. The server 540 transmits information, such as commands, responses, and/or notifications, to the client 520.

The communications with the player 510 and/or the client 520 may be handled by the communication component 572. The communication component 572 is adapted to communicate with one or more clients, such as client 520.

The game engine 570 is adapted to allow character development. In certain embodiments, character development is handled by the character development component 574. In certain embodiments, the character development component is adapted to allow a player 510 to develop a character 554. For example, the game engine 570 may allow a player 510 to spend experience points to adjust the attributes 556 or ancillary characteristics 558 of a character 554. As another example, the game engine 570 may allow a player 510 to add new attributes 556 or ancillary characteristics 558 to a character 554.

In certain embodiments, the character development component 574 supports automatic development of a character 554. For example, the character development component 574 may automatically adjust the values of attributes 556 and/or ancillary characteristics 558 associated with a character 554. As another example, the character development component 574 may automatically add new attributes 556 and/or ancillary characteristics 558 to a character 554.

In certain embodiments, the character development component 574 is adapted to automatically adjust attributes 556 of a character 554 based at least in part on an allocation selected by the correlation component 576. In certain embodiments, the character development component 574 is adapted to allow a player 510 to adjust attributes 556 of a character 554 based at least in part on an allocation selected by the correlation component 576.

The correlation component 576 is adapted to determine a correlation between the outcome data 564 and the allocation data 568. In certain embodiments, the correlation component 576 is adapted to determine which distribution of attributes 556 and/or associated attribute values corresponds to certain criteria. The criteria may be based at least in part on the outcome data 564. For example, the correlation component 576 may determine which attributes 556 tend to be associated with characters 554 that were on the winning side in more than a certain percentage of battles. As another example, the correlation component 576 may determine which distribution of attribute values among the attributes 556 of a character 554 tend to be associated with characters 554 that were on the winning side in more than a certain percentage of battles. The determined distribution of attribute values may include absolute values and/or relative values, for example.

In certain embodiments, the correlation component 576 is adapted to determine which choices made in improving a character 554 correspond to certain criteria. The criteria may be based at least in part on the outcome data 564. For example, the correlation component 576 may determine which attributes 556 had the largest increases in attribute value for characters 554 that were on the winning side in more than a certain percentage of battles. As another example, the correlation component 576 may determine which attributes were added to characters 554 that were on the winning side in more than a certain percentage of battles.

In addition, the correlation component 576 is adapted to select an allocation of attributes 556 based at least in part on the determined correlation. For example, the correlation component 576 may select a distribution of attribute values for the “strength,” “dexterity,” and “intelligence” attributes 556 based on the determined correlation. As another example, the correlation component 576 may select the “concealment” and “healing” attributes 556 based on the determined correlation. The selection may be based on what the determined correlation shows to be “average” performance, for example. The selection may be based on what the determined correlation shows to be above-average performance, for example.

In certain embodiments, the correlation component 576 is adapted to determine a plurality of correlations. For example, the correlation component 576 may determine a plurality of correlations where each correlation corresponds to a particular character type. As another example, the correlation component 576 may determine a plurality of correlations where each correlation corresponds to a particular character level.

In certain embodiments, the correlation component 576 is adapted to select a plurality of allocations of attributes 556 and/or attribute values based at least in part on the plurality of determined correlations. For example, the correlation component 576 may select one allocation of attributes 556 and/or attribute values for one type and/or level of character 554, and another allocation of attributes 556 and/or attribute values for another type and/or level of character 554.

FIG. 6 illustrates an exemplary screen configuration for a development user interface 600 that allows a player to develop a character according to an embodiment of the present invention. The development user interface 600 may be displayed by a client similar to the client 120 or the client 520, described above, for example. The characters may be similar to the characters 554, described above, for example.

In certain embodiments, the development user interface 600 includes a selection interface 610, an adjustment interface 620, an acquisition interface 630, and a character display interface 640. The selection interface 610 allows a player to select a character from the collection of a player. The adjustment interface 620 allows a player to adjust attributes of the selected character. The acquisition interface 630 allows a player to add new attributes to the selected character.

In certain embodiments, the player may also adjust and/or add ancillary characteristics of the selected character. Certain ancillary characteristics may appear in the character display interface 640, for example. For example, the character display interface 640 may include the selected character's appearance and/or title. In certain embodiments, a player must spend experience points to adjust and/or add ancillary characteristics of the selected character.

In certain embodiments, the development user interface 600 is adapted to allow automatic adjustment of one or more attributes and/or ancillary characteristics of one or more characters. In certain embodiments, the adjustment interface 620 supports an option that distributes experience points according to a certain allocation scheme. For example, the allocation scheme could include evenly distributing experience points among a character's existing attributes. As another example, the allocation scheme could include distributing experience points based at least in part on a correlation between attribute allocations and competition outcomes of other characters. In certain embodiments, automatic allocation of experience points includes the automatic acquisition of new attributes.

FIG. 7 illustrates a flow diagram for a method 700 for selecting an allocation of character attributes in a gaming system in accordance with an embodiment of the present invention. The method 700 includes the following steps, which will be described in more detail. At step 710, a set of characters is selected. At step 720, outcome data is aggregated. At step 730, allocation data is aggregated. At step 740, a correlation is determined between the outcome data and the allocation data. At step 750, an allocation is selected based at least in part on the determined correlation. At step 760, the selected allocation is used to adjust one or more attributes of a target character. The method 700 is described with reference to elements of systems described above, but it should be understood that other implementations are possible.

At step 710, a set of characters is selected. The characters may be similar to the characters 554, described above, for example. In certain embodiments, the set of characters is selected by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example.

The set of characters may include one or more characters. The set of characters is selected from characters associated with one or more players. That is, the characters selected to be included in the set of characters may be selected from the collections of different players. In one embodiment, the set of characters includes all characters not in the collection of the current player. In certain embodiments, the set of characters includes one or more characters from the collections of one or more other players.

In certain embodiments, the set of characters is selected based on certain criteria. For example, a set of characters may be selected based at least in part on the characters' types and/or levels. As another example, a set of characters may be selected based at least in part on the amount of time that the players with whom the characters are associated have spent playing the game.

At step 720, outcome data is aggregated. The outcome data includes the results of one or more competitions engaged in by one or more characters. For example, the outcome data may include the results of battles, for example. As another example, the outcome data may include indicators of the number or percentage of competitions won and/or lost. The outcome data may be similar to the outcome data 564, described above, for example.

In certain embodiments, the outcome data is aggregated by a game engine. The game engine may be similar to game engine 150 or game engine 570, described above, for example. In certain embodiments, the outcome data is stored in a correlation database. The correlation database may be similar to the correlation database 560, described above, for example.

At step 730, allocation data is aggregated. The allocation data includes information on the allocation or distribution of attributes and/or attribute values for one or more characters. For example, the allocation data may include information on the allocation of one or more attributes and associated attribute values for one or more characters. As another example, the allocation data may include a record of one or more choices made when improving a character. The allocation data may be similar to the allocation data 568, described above, for example.

In certain embodiments, the allocation data is aggregated by a game engine. The game engine may be similar to the game engine 150, the game engine 250, or the game engine 570, described above, for example. In certain embodiments, the allocation data is stored in a correlation database. The correlation database may be similar to the correlation database 560, described above, for example.

At step 740, a correlation is determined between the outcome data and the allocation data. In certain embodiments, the correlation reflects which distribution of attributes and/or associated attribute values corresponds to certain criteria. The criteria may be based at least in part on the outcome data. For example, the correlation may reflect which attributes tend to be associated with characters that were on the winning side in more than a certain percentage of battles. As another example, the correlation may reflect which distribution of attribute values among the attributes of a character tend to be associated with characters that were on the winning side in more than a certain percentage of battles. The correlation may be based on absolute values and/or relative values of attribute values, for example.

In certain embodiments, the correlation reflects which choices made in improving a character correspond to certain criteria. The criteria may be based at least in part on the outcome data. For example, the correlation may reflect which attributes had the largest increases in attribute value for characters that are on the winning side in more than a certain percentage of battles. As another example, the correlation may reflect which attributes were added to characters that were on the winning side in more than a certain percentage of battles. The correlation may be determined by a correlation component similar to the correlation component 576, described above, for example.

At step 750, an allocation is selected based at least in part on the determined correlation. For example, an allocation of attribute values for the “strength,” “dexterity,” and “intelligence” attributes may be selected based on the determined correlation. As another example, an allocation adding “concealment” and “healing” attributes may be selected based on the determined correlation. The selection may be based on what the determined correlation shows to be “average” performance, for example. The selection may be based on what the determined correlation shows to be above-average performance, for example.

The allocation may be selected by a correlation component similar to the correlation component 576, described above, for example. The selected allocation may correspond to the allocation correlated with a highly desirable outcome.

At step 760, the selected allocation is used to adjust one or more attributes of a target character. In certain embodiments, the target character is selected by a game engine. The game engine may be similar to the game engine 150 or the game engine 570, described above, for example.

In certain embodiments, the target character is selected by a player. The player may be similar to the player 110 or the player 510, described above, for example. For example, a player may select a target character from the player's collection.

One or more attributes of the target character are adjusted, based at least in part on the selected allocation. The one or more attributes may be adjusted to bring the allocation of attribute values of the target character closer to the selected allocation, for example. For example, the attribute value of the target character's “strength” attribute may be increased where the relative attribute value for the “strength” attribute is higher in the selected allocation than in the target character's allocation.

In certain embodiments, the selected allocation is provided to a player. The player may adjust and/or add character attributes according to the selected allocation. The player may be similar to the player 110 or the player 510, described above, for example. For example, a development user interface may display to the player a set of possible attribute value adjustments for the “strength,” “dexterity,” and “intelligence” attributes associated with a character associated with the player. The development user interface may be similar to the development user interface 600, described above, for example. The character may be similar to the character 554, described above, for example. The player may then choose to adjust the attribute values for “strength,” “dexterity,” and/or “intelligence” to bring the character's attribute values closer to the selected allocation.

Certain embodiments of the present invention may omit one or more of these steps and/or perform the steps in a different order than the order listed. For example, some steps may not be performed in certain embodiments of the present invention. As a further example, certain steps may be performed in a different temporal order, including simultaneously, than listed above.

One or more of the steps of the method 700 may be implemented alone or in combination in hardware, firmware, and/or as a set of instructions in software, for example. Certain embodiments may be provided as a set of instructions residing on a computer-readable medium, such as a memory, hard disk, DVD, or CD, for execution on a general purpose computer or other processing device.

FIG. 8 illustrates a flow diagram for a method 800 for adjusting an ancillary characteristic of a character in a gaming system according to an embodiment of the present invention. The method 800 includes the following steps, which will be described in more detail. At step 810, a character is selected. At step 820, an ancillary characteristic associated with the character is selected. At step 830, an attribute associated with the character is selected based at least in part on the selected ancillary characteristic. At step 840, the ancillary characteristic value associated with the selected ancillary characteristic is adjusted based at least in part on the attribute value associated with the selected attribute.

At step 810, a character is selected. The character may be similar to the character 554, described above, for example. In certain embodiments, the character is selected by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example. In certain embodiments, the character is selected based on certain criteria. For example, a character may be selected each time the character advances to a new level. As another example, a character may be selected each time the character completes a competition, such as a battle. As another example, the character may be selected based on input from a player, such as player 510.

At step 820, an ancillary characteristic associated with the character is selected. The ancillary characteristic may be similar to the ancillary characteristic 558, described above, for example. In certain embodiments, the ancillary characteristic is selected by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example. The ancillary characteristic may be selected based on certain criteria. For example, an ancillary characteristic may be selected when the selected character gains experience points. As another example, the ancillary characteristics may be selected based on input from a player, such as player 510.

At step 830, an attribute associated with the character is selected based at least in part on the selected ancillary characteristic. The attribute may be similar to the attribute 556, described above, for example. In certain embodiments, the attribute is selected by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example.

In certain embodiments, an attribute is selected when the value of the selected ancillary characteristic is based at least in part on the attribute. For example, a “strength” attribute may be selected where the selected “appearance” ancillary characteristic depends at least in part on the attribute value of the “strength” attribute. As another example, a “axe skill” attribute may be selected where the selected “title” ancillary characteristic depends at least in part on the attribute value of the “axe skill” attribute.

At step 840, the ancillary characteristic value associated with the selected ancillary characteristic is adjusted based at least in part on the attribute value associated with the selected attribute. As discussed above, each attribute is associated with an attribute value. In addition, each ancillary characteristic is associated with an ancillary characteristic value. For example, an appearance ancillary characteristic may be associated with a value “image_warrior_(—)1.” The “image_warrior_(—)1” value may correspond to a particular image that can be displayed with the client 120 of a player 110. As another example, a title ancillary characteristic may be associated with a value “Axeman.”

In certain embodiments, the ancillary characteristic value is determined by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example. The ancillary characteristic value may be determined by comparing the attribute value to a predetermined threshold value, for example. When the attribute value exceeds a predetermined level, the ancillary characteristic value may be adjusted, for example. For example, when a character's axe skill exceeds a value of 5, the character's title ancillary characteristic may be adjusted to include the term “Axeman,” thereby indicating the character's proficiency with an axe. As another example, when a character's sword skill is in the top 10% of all characters in the gaming system, the character's title may be adjusted to include the term “Master Swordsman.”

In certain embodiments, a plurality of attributes is selected based at least in part on the selected ancillary characteristic. For example, the ancillary characteristic value may be determined by comparing two or more attribute values to a corresponding plurality of predetermined threshold values. As another example, a character's title may be adjusted based on multiple attribute values, determined by the class of the character. When a character has a class of “fighter,” the attribute values considered for adjusting the character's title may include strength and dexterity, for example. When a character has a class of “mage,” the attribute values considered for adjusting the character's title may include intelligence and wisdom, for example.

Certain embodiments of the present invention may omit one or more of these steps and/or perform the steps in a different order than the order listed. For example, some steps may not be performed in certain embodiments of the present invention. As a further example, certain steps may be performed in a different temporal order, including simultaneously, than listed above.

One or more of the steps of the method 800 may be implemented alone or in combination in hardware, firmware, and/or as a set of instructions in software, for example. Certain embodiments may be provided as a set of instructions residing on a computer-readable medium, such as a memory, hard disk, DVD, or CD, for execution on a general purpose computer or other processing device.

FIG. 9 illustrates a flow diagram for an example 900 according to the method 800 for adjusting an ancillary characteristic of a character in a gaming system. The example 900 includes the following steps, which will be described in more detail. At step 910, Character 1 is selected. At step 920, the TITLE ancillary characteristic associated with Character 1 is selected. At step 930, the SKILL_AXE attribute associated with Character 1 is selected. At step 940, the ancillary characteristic value associated with the TITLE ancillary characteristic is adjusted based on the attribute value associated with the SKILL_AXE attribute.

At step 910, Character 1 is selected. Character 1 may be similar to the character 554, described above, for example. In certain embodiments, Character 1 may be selected by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example. Character 1 may be selected based on certain criteria. For example, Character 1 may be selected when Character 1 advances to a new a level. As another example, Character 1 may be selected based on input from a player, such as player 510.

At step 920, the TITLE ancillary characteristic associated with Character 1 is selected. The TITLE ancillary characteristic may be similar to one of the ancillary characteristics 558, described above, for example. In certain embodiments, the TITLE ancillary characteristic may be selected by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example. For example, the TITLE ancillary characteristic may be selected each time that Character 1 advances to a new level. As another example, the TITLE ancillary characteristic may be selected based on input from a player, such as player 510.

At step 930, the SKILL_AXE attribute associated with Character 1 is selected. The SKILL_AXE attribute may be similar to an attribute 556, described above, for example. In certain embodiments, the SKILL_AXE attribute may be selected by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example. The SKILL_AXE attribute is selected based at least in part on the TITLE ancillary characteristic. For example, the SKILL_AXE attribute may be selected because the ancillary characteristic value associated with the TITLE ancillary characteristic is a function of the attribute value associated with the SKILL_AXE attribute.

At step 940, the ancillary characteristic value associated with the TITLE ancillary characteristic is adjusted based on the attribute value associated with the SKILL_AXE attribute. As discussed above, each ancillary characteristic is associated with an ancillary characteristic value, and each attribute is associated with an attribute value. In certain embodiments, the ancillary characteristic value associated with the TITLE ancillary characteristic may be adjusted by a character development component. The character development component may be similar to the character development component 258 or the character development component 574, described above, for example.

The ancillary characteristic value associated with the TITLE ancillary characteristic is adjusted by comparing the attribute value of the SKILL_AXE attribute to a certain threshold value. For example, if the attribute value of the SKILL_AXE attribute is equal to or greater than a threshold value X, the ancillary characteristic value associated with the TITLE ancillary characteristic may be set to “Axeman.” As another example, if the attribute value of the SKILL_AXE attribute is less than a threshold value X, the ancillary characteristic value associated with the TITLE ancillary characteristic may be left unchanged. In other words, when a character's skill with an axe increases above a particular level, the character's title may be adjusted to reflect the character's skill as an axeman.

Thus, certain embodiments of the present invention provide a gaming system that provides customization of a character based at least in part on attributes of the character. In addition, certain embodiments of the present invention provide a gaming system that allows a casual gamer to be competitive with players who micro-manage their characters. Further, certain embodiments of the present invention provide systems and methods for character development in online gaming. Certain embodiments of the present invention provide a technical effect of a gaming system that provides customization of a character based at least in part on attributes of the character. Certain embodiments of the present invention provide a technical effect of a gaming system that allows a casual gamer to be competitive with players who micro-manage their characters. Certain embodiments of the present invention provide a technical effect of character development in online gaming.

While the invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims. 

1. A method for selecting an allocation of character attributes in a gaming system, the method including: selecting a set of characters, wherein the set of characters includes at least one character, wherein each character in the set of characters includes a set of attributes, wherein each set of attributes includes at least one attribute, wherein each attribute has an associated attribute value adapted to be adjusted, wherein each character is associated with an outcome record, wherein each outcome record is based at least in part on a competition; aggregating outcome data, wherein the outcome data is based at least in part on the outcome records; aggregating allocation data, wherein the allocation data is based at least in part on each set of attributes and the attribute values associated with each attribute in each set of attributes; determining a correlation between the outcome data and the allocation data, wherein the correlation is based at least in part on which attributes and attribute values correspond to which outcomes; and selecting an allocation based at least in part on the determined correlation.
 2. The method of claim 1, further including adjusting the allocation of attributes of a target character automatically based at least in part on the selected allocation.
 3. The method of claim 2, wherein the target character is not included in the set of characters.
 4. The method of claim 1, further including providing allocation information to a player, wherein the allocation information is based at least in part on the determined correlation.
 5. The method of claim 4, wherein the player adjusts at least one attribute value based on the allocation information.
 6. The method of claim 5, wherein the at least one attribute value adjusted by the player is associated with a target character not included in the set of characters.
 7. The method of claim 1, wherein the step of selecting the set of characters includes selecting a character from a plurality of available characters based at least in part on a class.
 8. The method of claim 1, wherein the step of selecting the set of characters includes selecting a character from a plurality of available characters based at least in part on a level.
 9. The method of claim 1, wherein the step of selecting the set of characters includes selecting a character from a plurality of available characters based at least in part on a play style.
 10. The method of claim 1, wherein the step of selecting the set of characters includes selecting a character based at least in part on at least one attribute.
 11. A method for adjusting an ancillary characteristic of a character in a game, the method including: selecting a character, wherein the character is associated with at least one ancillary characteristic, wherein each ancillary characteristic is associated with an ancillary characteristic value, wherein the character is associated with at least one attribute, wherein each attribute is associated with an attribute value, wherein each attribute value is adapted to be adjusted by a player; selecting an ancillary characteristic associated with the character, selecting an attribute associated with the character based at least in part on the selected ancillary characteristic; and adjusting the ancillary characteristic value associated with the selected ancillary characteristic based at least in part on the attribute value associated with the selected attribute.
 12. The method of claim 11, wherein the character is selected from a set of characters.
 13. The method of claim 12, wherein the set of characters is associated with the player.
 14. The method of claim 11, wherein the character is adapted to be exchanged.
 15. The method of claim 11, wherein the character is adapted to participate in a competition.
 16. The method of claim 11, wherein the step of selecting the attribute includes selecting a plurality of attributes associated with the character based at least in part on the selected ancillary characteristic.
 17. The method of claim 12, wherein the adjusting step includes adjusting the ancillary characteristic value based at least in part on attribute values associated with the plurality of selected attributes.
 18. A computer-readable medium including a set of instructions for execution on a computer, the set of instructions including: a character set routine configured to support a character set, wherein the character set is adapted to include at least one character, wherein each character in the character set includes at least one attribute, wherein at least one attribute of each character in the character set is adjustable by a player; and a character development routine configured to allow the player to adjust the at least one attribute of each character in the character set.
 19. The set of instructions of claim 18, further including a correlation routine configured to determine a correlation between a set of attribute allocations and a set of competition outcomes, wherein the character development routine is configured to adjust the at least one attribute based at least in part on the correlation.
 20. The set of instructions of claim 18, wherein the character development routine is configured to adjust an ancillary characteristic of a character in the character set. 